In current settop boxes (STBs,) and broadcast receivers, processing that separates multiplexed transport stream data into various types of data (such as video data and audio data) is performed by hardware. Accordingly, the FIFO buffer (fixed to a size determined by the maximum bit rate of input transport stream data), required to temporarily store input transport stream data, is realized as part of the hardware.
The bit rate of the input transport stream data differs depending on the country, the broadcaster, etc. Accordingly, after using the hardware to determine the design, as described above, when an STB for another destination or another broadcaster is developed, a problem arises in that since the bit rates of the input transport stream data differ, the hardware design must be substantially modified to achieve optimal size (area) so as to prevent the input transport stream data from overflowing.
In digital broadcast receiving devices such as settop boxes (“STBs”), etc., a multiplexed transport stream of digital data is received for processing. An overview of standards for digital transmission is seen in the International Standard ISO/IEC 13818-1 “Information Technology—Generic coding of moving pictures and associated audio information: Systems,” (hereinafter “MPEG 2”) which is herein incorporated by reference. Although the discussion of prior art is directed to the transport stream architecture used in MPEG 2 for exemplary purposes, it is understood that the invention disclosed herein may be used in conjunction with any packetized digital stream of data.
Within MPEG 2 transmission, digital data, such as the video portion of a movie, is originally packetized into PES Packets which together form the packetized elementary stream (“PES”). PES packets are variable in length, including a 6 byte protocol header and an optional protocol header. Because of a variety of technical limitations, from synchronization, jitter control, and error management, packets of this length are not well suited for point-to-point broadcasts in a broadcast media. Within MPEG 2 therefore, separate standards exist for “lossless” environments, such as a DVD movie being shown at home, and “lossy” environments, such as point-to-point digital broadcasts. The preferred approach for a “lossless” medium is a “program stream” and the preferred standard for a “lossy” medium is a transport stream (TS). Within a Transport stream, each PES packet is further divided up into standardized transport stream packets (“TSP”s) which are defined by a fixed length of 188 bytes. FIG. 1 shows digital audio information 100 being packetized into a set of variable length PES packets 102-110. Further packetization is illustrated using PES audio packet C 106, which is seen to be further packetized into multiple fixed length transport stream packets 120-126. As noted, the MPEG 2 standard has fixed these packets to a length of exactly 188 bytes. FIG. 2 illustrates digital video information 200 being packetized into variable length PES packets 202-210. PES video packet C 206 is seen to be further packetized into multiple fixed length transport stream Packets 220-228.
FIG. 3 illustrates how a PES packet is broken up and stored in a series of transport stream packets. A simplified PES packet 300 is shown comprising a header 302 and a data payload 304. Although a PES packet is a continuous stream of data, the payload 304 is broken up into imaginary partitions 306-312 for illustrative purposes, delineated by dotted lines. The PES packet is sent in a series of transport stream packets 320, 322, 324 and 326. Each of the transport steam packets 320-326 include a header and a data payload. When broken up and stored in a series of transport stream packets 320-326, the PES header 302 is stored in the first portion of the payload 340 of the first transport stream packet 320. The remaining area of the payload 340 of the first transport stream packet 320 is filled with data 306 from the PES packet payload 304. The next data 308 from the PES packet payload 304 is stored in the payload 342 of the second transport stream packet 322. The next data 310 from the PES packet payload 304 is stored in the payload 344 of the third transport stream packet 324. The process continues through to the last data 312 in the PES packet payload 304 which is stored in the payload 346 of the last transport stream packet 326 formed from that PES packet 300. Because all transport stream packets must be 188 bytes in length, if the last remaining data 312 from the PES payload 304 is not large enough to fill the payload 346 of the final transport stream packet 326, the unused portion of the final payload 346 is filled with stuffing bytes 0xFF (all ones).
FIG. 4 is a more detailed representation of a PES Packet as seen in FIGS. 1 (102-110), FIG. 2 (202-210) and FIG. 3 (300). According to FIG. 4, a PES Packet 400 comprises a six-byte header 402, an optional PES header 404 ranging from three to two-hundred fifty-nine bytes, and a payload 406 of up to 65,526 bytes. The PES packet header 402 itself comprises a three-byte start code prefix 410, a one-byte Stream ID 412, and a two-byte PES packet length indicator 414. Some well known Stream IDs 412 include:
1. 110x xxxx—MPEG-2 audio stream number x xxxx.
2. 1110 yyyy—MPEG-2 video stream number yyyy; and
3. 1111 0010—MPEG 2 DSC-CC control packets.
The PES optional header 404 includes a two bit PES_Scrambling_Control 422 which defines whether scrambling is used and the chosen scrambling method, a 1 bit PES13 Priority indicator 424 which indicates the priority of the current PES packet 400, a one-bit data alignment indicator 426 for indicating if the payload 406 starts with a video or audio start code, a one-bit copyright indicator 428 showing if the information contained within the payload is copyright protected, a one-bit original-or-copy indicator 430 showing if this is a copy or an original elementary stream. The one-byte flag field 432 indicates whether certain other optional fields exist in the optional field 436 area. These flags 432 (and their corresponding optional data fields if they exist) include a “presentation time stamp” (“PTS”), and a “decode time stamp (“DTS”) flag 440. The decode time stamp is necessary because video pictures may arrive at the decoder in a different order than they will be presented. Accordingly, it is possible that a picture will have to be decoded some time before it is presented for viewing in order to allow the decoded portion to act as a reference for a B picture. The DTS therefore indicates the time wherein the packet must be decoded. The PTS indicates the time when the picture must be presented. As discussed in conjunction with FIGS. 6 and 7, the PTS and DTS time stamps are encoded by the encoder's clock. The decoder clock must therefore reference itself to these time stamps. These presentation time stamps and decode time stamps which are introduced at the PES level should not be confused with the program clock reference (PCR) 516 (FIG. 5) which is stored in the adaptation field 514 of a transport stream packet 504, and also explained further in conjunction with FIG. 7.
Returning to the PES packet, an ESCR flag 442 indicates the presence of an elementary stream clock reference in the optional field 436. An elementary stream rate flag 444, if on, signals an optional field with information on the rate at which the elementary stream was encoded. The trick mode flag 446 indicates that the audio or video is not the normal elementary stream. This might occur, for example, after DSM-CC has signaled a replay. Following the additional copy info flag 448, the PES CRC flag 450 indicates the presence of a cyclical redundancy checksum within the optional field 436 to facilitate error checking for the previous PES packet. The PES extension flag 452 indicates the presence of data used for supporting MPEG-1 streams. Because the presence of optional fields 436 indicated by these flags creates an uncertain length of the total header area, a one-byte PES header data length field 434 helps define the total length of the header, which has the corollary effect of defining the length of the payload 406. Stuffing bytes 438 may be used to fill out a PES packet to a desired length.
FIG. 5 discloses the syntax of a transport stream packet according to MPEG 2 standards. In order to manage the transport stream 616 (FIG. 6) and identify the component packets 120-126 (FIG. 1), 220-228 (FIG. 2), within the transport stream 616, each transport stream packet (“TSP”) has various overhead fields. Each transport stream packet 502, 504, 506, holds exactly 188 bytes. Each packet 502-506 is made up of a header 508 and a payload 510. The illustration of FIG. 5 includes a blow-up or expanded portion of the header 508, which is seen to include a packet identifier or PID field 512 among other fields. The PID field 512 is currently thirteen bits in length, ranging in hex values from 0000 to 1FFF, currently assigned as follows:
TABLE IValues for PID FieldValueDescription0×0000Program Association Table0×0001Conditional Access Table0×0002Transport Stream Description Table0×0003-0×000FReserved0×0010 through 0×1FFEMay be assigned as network_PID,Program_map, elementary-PID, or for otherpurposes.0×1FFFNull Packet
According to the Table I, the PIDs in the range of 0x0010 through 0x1FFE are used as identifiers for a particular type of data in a data stream, thereby distinguishing the audio and video packets of FIGS. 1 & 2. As previously noted, the “type” of data, whether audio or video, is stored in the PES packet. Accordingly, the PID is not used to designate the “type” of data, but is simply an identifier arbitrarily assigned to a particular collection of transport stream data packets. As noted earlier, the transport stream packet 504 includes a program clock reference (PCR) 516 in the adaptation field 514, the function of which will be explained further in conjunction with FIG. 7.
The fragmentation of the PES Packet 300 into multiple transport stream packets according to FIGS. 1-3 is not the final step in creating a transport stream. FIG. 6 illustrates a block diagram of a system for encoding, packetizing and multiplexing audio and video data into a transport stream. Video data 602 is input into a video encoder 604 where the video data is appropriately encoded. The encoding process refers to the preparation of PES packets, and may also involve the use of various compression schemes for the payload of the PES packet. MPEG 2 does not specify or limit the data format in the payload of the transport stream packet, and only sets forth a standard for the syntax of the transport stream packets themselves. Accordingly, the video encoder 604 and audio encoder 610 have the capability to utilize data compression techniques, or any other form of data manipulation. MPEG 2 transmission is not dependent on the type of data being stored in the payload. The data may be compressed, uncompressed, audio, video, games, or software. However, it is vital that the decoder at the other end of the stream is compliant, or the information in the PES payload will be meaningless. When transmitting audio and video data, the decode time stamp (DTS) and presentation time stamp (PTS) are added during the encoding process. These time stamps are not needed for other types of data which can theoretically be transmitted over MPEG 2, such as software, games, or still photographs.
An output of the video encoder 604 is coupled to a packetizer circuit 606 where the encoded video data is packetized, forming a PES stream. Audio data 608 is input into an audio encoder 610 where the audio data is appropriately encoded. An output of the audio encoder 610 is coupled to a packetizer circuit 612 where the encoded audio data is also packetized, forming an audio PES stream. Presentation time stamps and decode time stamps are typically generated at the encoders 604, 610, and respectively inserted into the PES packet header 404 by the packetizers 606, 612. As a result, video and audio data which are related, belonging to the same TV program or movie, are marked with the same time stamp by encoders using the same clock reference. Accordingly, the video and audio portions of the same movie or TV program, though transported in separate digital packets, can be reconstructed and synchronized at the output, thereby maintaining “lip synch.” The packetized video data from the packetizer circuit 606 and the packetized audio data from the packetizer circuit 612 are then sent to a transport stream multiplexer circuit 614 where the packets of encoded audio and video data are then multiplexed together into a single transport stream 616. Accordingly, the transport stream packetization illustrated in FIGS. 1-3 takes place in the transport stream multiplexer 614 of FIG. 6. The transport stream multiplexer 614 then generates a time-multiplexed stream of data 616 as represented by the transport stream packets 220, 222, 120, 224, 122, 124, from FIGS. 1 and 2.
A time stamp called a program clock reference 516 (FIG. 5) is embedded in the extended header of select audio or video transport stream packets at the transport stream packetizing and multiplexing stage. The clock references occur at intervals up to 100 msec in a transport stream. Accordingly, MPEG standards require that the PCR be transmitted at least once every 100 msec. When the data stream is eventually received at an output, a phase-lock loop is used by the receiver to synchronize the receiver to the PCR value in the transport stream packet, and to adjust the local clock accordingly. This ensures that the movie or TV program will be displayed at the same speed it is being transmitted, without faster or slower portions. This feature is needed largely because transport stream packets are introduced to the transport stream asynchronously. That is, the length of time separating two successive video transport stream packets may be longer than the “actual” time separating the moving events pictured by the packets. Similarly, two packets may be transmitted consecutively with less transmission time separating them than actually occurred in real life. Without PCR values to guide the receiver, a video display would undulate—in an “accordion” fashion . . . fast, slow, fast, slow—according to the time between transport stream video packets. With the PCR values, the receiver regulates the presentation of the data to the same speed at which it was transmitted. This is particularly important in a “lossy” environment such as broadcast transmission. If a certain fraction of packets are interrupted due to noise or interference, the receiver can, upon receipt of the next PCR value, re-orient itself with the broadcaster. If, however, because the multiplexing of audio and video components of the same TV program are asynchronous, the program clock reference within the transport stream packets does not guarantee that the relative stream position of the audio packets to the video packets creates a proper time reference between them.
FIG. 7 shows the time-multiplexed transport stream 616 of FIG. 6 as it is demultiplexed and processed into the original digital audio information 100 and video information 200. The transport stream 616 enters an input of a transport stream demultiplexer 702, which separates the transport stream 616 into separate audio and video components. The video component is transmitted from a video output of the transport stream demultiplexer to an input of a video decoder 706 and output as a decoded video stream 710. The audio component is transmitted from an audio output of the transport stream demultiplexer 702 to an input of an audio decoder 708 and output as a decoded audio stream 712. As noted, if a video packet must be examined in an order different than it is to be presented to help interpret the contents of other packets, the decode time stamp value will define this order. The presentation time stamp values relate video and audio data from the same movie to ensure lip synch between the video and audio portions. The decoder clock must therefore reference itself to these time stamps. The decode and presentation time stamp values are static in the sense that they are equally applicable for a broadcast transmission of a movie, or the storage of a moving picture on a DVD. The program clock reference value, on the other hand, is necessary only in transport stream environments such as broadcast video, wherein a receiver must remain synchronized.
In digital TV broadcasting, multiple TV programs and movies can be multiplexed into a single MPEG-2 transport stream, forming a multicast. The audio and video encoders for the same movie must be synchronized to the same clock to ensure synchronization, but unrelated movies and programs need not be synchronized, and therefore, may be encoded independently using different encoders with different time bases. FIG. 8 is similar to FIG. 6, but illustrates the multiplexing process when multiple TV programs or movies are multiplexed into a single transport stream. Program—1 is a musical TV program of a vocal concert. The video data 802 from program—1, symbolized in FIGS. 8-10 by a human figure, enters the input of the first video encoder 804. After encoding, it is directed to the input of a PES packetizer 806, forming the video—1 program elementary stream (PES) 816. The audio data 810 of program—1, symbolized by a musical note, enters the input of the first audio encoder 812. After encoding, it is directed to the input of a PES packetizer 814, forming the audio—1 PES 818. Clock 1 808 is used to create a common time base for the presentation time stamps stored within the optional field 436 of the PES packet of FIG. 4. These time stamps are thereby embedded in the packets comprising the video—1 program elementary stream 816 and the audio—1 program elementary stream 818, thereby ensuring that they are referenced against the same time base. This allows the decoding process to synchronize the video and audio portions of program—1 when the concert is reproduced at a user output such as a TV. English subtitle—1 data 852 is used for exemplary purposes to illustrate that any number of other component parts, such as subtitles, could be associated with program—1. Because subtitles must be synchronized with the audio and video portions, the PES packetizer 854 of the English subtitle 1 data is also controlled by the clock 808 associated with program—1.
Program—2 is a movie, the video portion of which is graphically symbolized by a dog. The video data 820 from program—2 enters the input of the second video encoder 822. After encoding, it is directed to the input of a PES packetizer 824, forming the video—2 program elementary stream 832. The audio data 826 of program—2, symbolized by a graph of a sound envelope of a dog barking, enters the input of the second audio encoder 828. After encoding, it is directed to the input of the audio PES packetizer 830, forming the audio—2 PES program elementary stream 834. Program—2 is also seen to have an English subtitle component 860 which is similarly processed. Clock 2 is similarly used to generate a common time base for the presentation time stamps stored in the optional field 436 of a PES packet as illustrated in FIG. 4. The presentation time stamps are thus embedded in the video—2 PES packets forming the video—2 program elementary stream 832, the audio—2 PES packets 834 and the English subtitle—2 PES packets 864 to allow synchronization upon decoding. Because program—1 and program—2 are unrelated, and do not need to be synchronized with each other, separate clocks 808, 836 may be used for the separate programs. The video—1 program elementary stream 816, audio_1 program elementary stream 818, English subtitle—1 program elementary stream 856, video—2 program elementary stream 832, audio—2 program elementary stream 834, and English subtitle—2 program elementary stream 864 are input into a transport stream multiplexer 840. The multiplexer 840 further packetizes the PES packets into transport stream packets, as previously illustrated in FIGS. 1-3 discussed above, and time multiplexes them into a common multi-program transport stream 850, as further illustrated in FIGS. 9 and 10. The clock circuit 3 842 is coupled with the transport stream multiplexer 840 to generate program clock reference (PCR) time stamps stored in the PCR field 516 (FIG. 5) of the packets within the transport stream 850. These time stamps are embedded in select transport stream packets 1002, . . . , 1028 (FIGS. 10, 11).
FIG. 9 illustrates an example of two transport streams TS1 and TS2 multiplexed into a single transport stream, TS3. Packets from the transport stream TS1 are illustrated as having a series of time stamps from a first multiplexing process, the time stamps represented as PCR 1-a and PCR 1-b. Similarly, the packets from the transport stream TS2 are illustrated as having a series of time stamps from a second multiplexing process, the time stamps represented as PCR 2-1 and PCR 2-b. When the two transport streams TS1 and TS2 are multiplexed into a single transport stream, TS3, the multiplexing process strips out the old PCR time stamps from the transport stream packets of TS1 and TS2, and inserts new PCR time stamps, illustrated as PCR 3-a, PCR 3-b, PCR 3-c and PCR 3d in the succession of transport stream packets. In addition to updating some of the time stamps, other overhead features such as new PIDs are typically updated as well, and new program map tables PMTs are generated to reflect the information contained in the new combined stream. These overhead changes are largely transparent to the end user, however, and the payload data from the original data stream remains unaffected when the streams are combined. FIG. 9 illustrates packets comprising payload data and select overhead data being combined from the transport streams TS 1 and TS 2 into the transport stream TS3. The illustration shows the select overhead data being updated in transport stream 3 while the payload data in the form of Video 1 and Video 2 remain unaffected.
FIG. 10 is an illustration of an exemplary multi-program transport stream 850 generated through the multi-program multiplexing apparatus of FIG. 8. The multi-program transport stream 850 is comprised of a series of transport stream packets 1002, . . . , 1028. In this example, video—1 transport stream packets 1002, 1012, 1024 have been assigned a PID of 0027h by the transport stream multiplexer 840 of FIG. 8. The audio—1 transport stream packet 1006 has been assigned a PID of 0034h, the video—2 transport stream packets 1004, 1010, 1020 have been assigned a PID of 0061h, and the audio—2 transport stream packet 1016 has been assigned a PID of 0042h. Two separate English subtitles transport stream packets 1026, 1028 are respectively assigned PIDs of 0039h and 0051h, and a French subtitle transport stream packet 1022 has been assigned the PID of 0072h.
Because the time-multiplexing is asynchronous, there is no reliable way of relating a subtitle or audio portion of a program or movie to its respective video portion simply by its respective position in the transport stream 850. In order to relate the correct component parts of the same program during output processing, multi-program transport streams 850 have additional transport stream packets not typically found in the single program transport stream 616 (FIG. 6). These additional transport stream packets include a program association table (PAT) 1008, which is always assigned a PID of zero, and multiple program map tables (PMTs) 1014, 1018. The function of these transport stream packets can be understood by examining the blow-up versions of the PAT 1008 and the PMTs 1014, 1018 in FIG. 10. The PAT 1008 lists all programs currently included in the transport stream. As seen in FIG. 10, there are five programs, each cross referenced to PID numbers representing that program. For as many programs as are referenced in the PAT 1008, the transport stream includes a program map table (PMT) designated by the PID referenced in the PAT 1008. Program—1 has a PID value of 0025h, and program—2 has a PID value of 0057h. Examining the blow up of the PMT 1016 of program—1, it is seen that the video transport packets having a PID value of 0027h, the audio transport stream packets having a PID value of 0034h, and the English subtitle transport stream packets having a PID value of 0039h are all component parts of program—1, the vocal concert. Similarly, examining the blow up portion of PMT 1018 of program—2, it is seen that the video transport stream packet having a PID value of 0061h, the audio packets having a PID value of 0042h, the English subtitle packets having a PID value of 0051h and the French subtitle packets having a PID value of 0072h are all component parts of program—2, an animal movie. By regular transmission of the PAT 1008, a broadcast receiver is able to know how many programs are present, and the PID of the respective PMTs 1014, 1018 of those respective programs. A “channel selection” or program schedule for cable TV may thus be generated with the assistance of the PAT 1008. Once a user selects a particular channel or program, the broadcast receiver 1200 (FIG. 12) identifies the component parts of that channel by referencing the PMT 1014, 1018 of that particular channel. It should be understood that the other programs 3, 4, 5 within the PAT also have a corresponding PMT.
FIG. 11 shows the multi-program transport stream 850 of FIGS. 8 and 10 being filtered through a prior art filtering table 1102 of a broadcast receiver. Upon selection of a program by a user, the PAT identifies the PMT for that program. In the example of FIG. 11, the filtering table 1102 can be seen to hold the PAT 0000h, the PMT 0025h for program—1, and the video 0027h, audio 0034h, and subtitles 0039h associated with program—1 according to the PMT 1014. Additionally, the filtering table 1102 identifies two hypothetical overhead PIDs, 00A2 and 07B0. According to the exemplary system illustrated in FIG. 11, therefore, there are currently seven PIDs identified in the filtering table 1102. The filtering table 1102 acts to receive only those transport stream packets defined by an approved PID listed in the filtering table 1102. An examination of the transport stream packets 1002, 1006, 1008, 1012, 1014, 1024, 1026 stored in the filtered packet input FIFO buffer 1104 discloses that they are the same packets in the same order as found in the multi-program transport stream 850, except that those packets identified by PIDs not listed in the filtering table 1102 have been filtered out, and are not stored in the filtered packet input FIFO buffer 1104. Only the approved transport stream packets 1002, 1006, 1008, 1012, 1014, 1024, 1026 from the transport stream 850 which include PID values matching those within the filtering table 1102 are received and stored in a general input FIFO buffer 1104. From the general input FIFO buffer, the filtered transport stream packets are sent to a demultiplexer 1106, and are separated into their component PIDs in various component buffers, such as an audio buffer 1108 for packets that include the audio PID 0034h, and a video buffer 1110 for video packets that include the PID 0027h.
Filtering tables currently used in broadcast receivers typically have thirty-two PID registers to select transport stream packets. Because filtering tables currently in use are a fixed hardware component, broadcast receivers cannot be configured for filtering more than thirty-two distinct PIDs. There are two disadvantages of this fixed architecture. First, the number of PIDs required to be included in the filtering table could exceed the capacity of the filtering table. To upgrade a fixed architecture filtering table requires a costly hardware update. Moreover, upgrading a filtering table with a new fixed architecture filtering table of greater capacity does not resolve all issues. It is commonly recognized by those skilled in the art that digital devices normally operate at a more rapid speed in the “lower” addressable regions. Accordingly, if a filtering table were expanded to some great number of registers, it would be very flexible, but not optimal in terms of speed or cost. These conflicting interests create a dilemma in the manufacture of filtering tables. An optimal filtering table is the smallest size necessary to function in a given application at a given time. However, the most flexible filtering table is the one with the largest capacity, such that it can store more PIDs or other parameters as more PIDs are allocated to define more kinds of data.
A second limiting factor in fixed architecture filtering tables is the bit field for storing the PID. Currently, as established by international standard ISO/IEC 13818-1, the PID bit field is thirteen bits. If international standards increase the bit field 512 (FIG. 5) designated for storage of the PID in MPEG 2 from thirteen bits to some greater number, present fixed architecture filtering tables will be obsolete, and must again be upgraded. Again, however, creating an unnecessary large bit field for “growth” is again a sub-optimal solution. The same dilemma, optimum flexibility for growth vs. optimum efficiency in cost and performance is repeated.
Another limitation of the prior art is experienced through the actual data storage. An optimal FIFO Buffer 1104 is the smallest necessary to store the incoming data. However, the bit rate of a data transport stream 850 differs according to country, broadcaster, and even through momentary changes in the system use. Because the FIFO Buffer 1104 and the post-multiplexing buffers 1108, 1110 must be able to store incoming data as fast as it is received through the filtering table 1102, a fixed hardware structure as presently used limits the rate at which input data may be received. With fiber optical transmission and processing technology advancing rapidly, the ever faster input rates for incoming data create the corollary need for a greater capacity among the input buffers. Alternatively, faster processing of incoming software might reduce the required size of any of the input buffers 1104, 1108, 1110. Similarly, without any changes in transmission rate or processing speeds, one program may have five languages, and closed captioning in each. Another may simply be broadcast in one language with no closed captioning. These differences mean that different amounts of data will be filtered through the filtering table and marked for storage in the various buffers, requiring buffers of greater or lesser storage capacity. Accordingly, even without technological advances, the input tables 1104, 1108, 1110 may prove too small, thereby limiting the programming receivable by the broadcast receiver, or too large, thus being sub-optimal. The same dilemma arises again in fixed architecture data buffers such as the filtered packet input FIFO buffer 1104, and the post-multiplexing data buffers such as the audio buffer 1108 and video buffer 1110. The optimal size on a FIFO input buffer 1104 for performance and cost is typically the smallest size necessary to satisfy system demands. However, if the FIFO input buffer 1104 is optimized to the smallest functional buffer, as the bit rate increases for any variety of reasons, the hardware comprising the FIFO input buffer 1104 must be replaced with a buffer of greater capacity to prevent the filtered transport stream data from overflowing. Similarly, the audio buffer 1108 and video buffer 1110 may not be increased or decreased without new hardware.
A final limitation of the prior art stems from the fact that hardware is configured for a fixed number of “filtered-data buffers” such as the audio buffer 1108 and the video buffer 1110. A broadcast in forty languages would require not only forty or more registers in the filtering table 1102, it could, depending on the architecture, require over forty post-demultiplexing buffers 1108, 1110 in which to segregate incoming data. Once again, a hardware architecture which is mapped with a fixed number of filtered-data buffers must be replaced with a new chip to respond to the changing demands for the number of storage buffers, as well as the capacity of each of those buffers as already noted. With a fixed architecture, the alternatives are, again, conflicting. A broadcast receiver with a greater number of buffers 1104, 1108, 1110 is more flexible, but a broadcast receiver with the minimal number of buffers necessary is optimal in terms of cost and efficiency.